Virtually every business today relies heavily upon computers. Such reliance includes the use of computers for human resources management; book keeping; shipping; inventory control; purchasing; sales and customer relationship management, to name but a few. Even businesses of modest size can generate very substantial amounts of data that must be tracked and/or managed using computers. These systems may be acquired individually over time or construed as a comprehensive integrated business solution that can address all of the businesses needs with a single integrated solution.
In general, it is extremely rare that a given piece of software will meet each and every criteria of the business in an as-shipped state. Accordingly, there is usually a significant amount of customization and/or coding that must be done to tailor software to an individual business' needs.
As a business grows and relies upon its computer system, the databases and other related files in the business software system can grow very large. Accordingly, when a business considers whether to upgrade its business software to a competing system, one significant concern is the cost of migrating data from the legacy system(s) to the new system. This can be an extremely daunting task because the legacy system may be comprised of any number of systems that may be incompatible with each other, or the upgrade system and which systems may be located in geographically diverse locations. Thus, simply getting all of the business data together in one place and working with it in order to provide it into the new system can require large amounts of time from extremely skilled software technicians and/or developers. Thus, one significant barrier of widespread adoption of new and improved business software systems is the pain of data migration.
Traditionally, migration tools used to move data from one business system to another used a set of hard-coded rules to create a business object in the destination system from a set of pre-defined fields in the source system. This prior art approach is illustrated in FIG. 2 that shows sources of legacy business data 200, 202, 204 providing an input to hard-coded data extraction tool 206 that provides the data to destination system 208. This traditional approach has two significant drawbacks. First, it does not enable the migration tool 206 to survive any changes in the layout of either the source or destination databases. Changes to the destination database schema may actually occur when future releases of the destination system ship, or when patches or upgrades are applied to the destination system to address any possible issues with the destination system. Secondly, the destination system may have an extensible architecture that enables users to customize business objects by defining their own set of properties. In the past, the hard-coded set of rules were not aware of any database customizations and accordingly, were unable to adapt the extraction behavior to carry over any custom fields.